Multimedia Broadcast and Multicast Services (MBMS) is a broadcasting service offered via cellular networks. Enhanced MBMS (eMBMS) is correspondingly used to denominate MBMS service in Evolved Packet Systems, including Evolved Universal Terrestrial Radio Access Network (E-UTRAN) for Long Term Evolution (LTE) cellular networks and UTRAN for e.g. Universal Mobile Telecommunications System, (UMTS) cellular networks. One simplified example of an eMBMS over LTE solution architecture is illustrated in FIG. 1.
The architecture 100 of FIG. 1 comprises at least one Broadcast Multicast Service Center (BM-SC) 110, which is an entity capable of providing MBMS or eMBMS by distributing content provided from one or more content service providers 120, where a content service provider 120 typically comprise a content store (not shown), and a live encoder (not shown), capable of providing content feeds e.g. in the form of satellite feeds, live feeds and/or Content Delivery Network (CDN) feeds to the BM-SC 110 under supervision of a Broadcast operations function 130, which is typically capable of interacting with the BM-SC 110. The BM-SC 110 is connected to an access network, typically comprising a plurality of access nodes, but for simplicity here represented by one single access node, eNB 140, via a Multimedia Broadcast Multicast Services Gateway (MBMS-GW) 150, where the eNB 140 is capable of distributing the provided content feeds to User Equipments (UE) located within range of the access network, via unicast or multicast. Here such UEs are represented by one single UE, UE 160.
In order to be able to remedy failure to receive the content feeds correctly, by at least one of the UEs, the architecture described above is typically also provided with functionality which is configured to enable the BM-SC 110 to re-transmit parts of the content feeds to those UEs 160 reporting failure to receive at least parts of the content feeds. Such a feature is typically referred to as file repair, or more specifically HTTP Unicast File repair. For enabling file repair, the BM-SC 110 is therefore normally provided with at least one, but typically with a plurality of file repair servers (not shown), capable of providing lost or corrupted file fragments of the content feeds to each requesting UE, by way of re-transmission of the previously transmitted data.
As stated above, eMBMS is a broadcasting service offered via Evolved Packet Systems including E-UTRAN LTE and UTRAN access. Two exemplifying use cases are described below:                1. To deliver e.g. sport games video content to mobile phones highly gathered in a stadium. eMBMS system can use the MBMS Download Delivery Method User Datagram Protocol, UDP/File Transport over Unidirectional Transport (FLUTE) as protocol to deliver Live TV content to terminals. Media segments according to Apple's HTTP Live Streaming (HLS) Protocol or according to DASH are delivered as files over MBMS Download,        2. Distribution of Android update. eMBMS system can use the MBMS Download Delivery Method (UDP/FLUTE) as protocol to deliver popular files, such as e.g. Android update, YouTube clip preloading or major news events.        
In this disclosure, the terms terminal, MBMS receiver, MBMS client and UE are used to denote a device or apparatus which is capable of receiving a broadcast transmission via MBMS or eMBMS, as described herein.
MBMS Download enables data file delivery on unidirectional MBMS bearers and improves file reception reliability by applying FEC technology. However, even though FEC is used, 100% reliability for data file delivery cannot be guaranteed.
Therefore, two other types of error recovery methods are defined, and optionally used, after an MBMS transmission has ended. With the Point-to-Point (PTP), File Repair method, an unsatisfied UE can fetch missing data using HTTP. The Point-to-Multipoint (PTM) File Repair method allows the BM-SC to send further MBMS data after the actual MBMS data transfer. The MBMS Service Layer specification does, however, not define any combinations or sequences of file repair methods.
MBMS download can be used to deliver an arbitrary number of data files from a single source to many UEs. MBMS Download may use the FLUTE [RFC3926] protocol for file delivery. FLUTE is designed for massive file delivery over unidirectional links, such as e.g. for digital broadcasts. Since HTTP and TCP are not feasible for PTM communication, a newly developed protocol is used. A typical eMBMS flute transmission according to the prior art is described below with reference to FIG. 2.
According to FIG. 2, which is a signalling diagram which in a simplified manner is illustrating MBMS or eMBMS downloading between a BM-SC 200 and MBMS or eMBMS enabled UEs, here represented by UEs 220a,220b, via a communication network (NW) 220 capable of handling MBMS or eMBMS respectively. From hereinafter the mentioning of MBMS is to be interpreted as meaning MBMS or eMBMS, and UEs may alternatively be referred to as MBMS or eMBMS clients. In FIG. 2 such a network infrastructure is represented by a Gateway (GW) 210 connecting NW 220 to the BM-SC 200, thereby providing access between the UEs, 220a,220b and the BM-SC 200.
In a first step 200, an MBMS bearer is established and an MBMS session is started by BM-SC 200. All files to be received by a UE require an entry in a FLUTE File Delivery Table, FDT, which is provided using FLUTE FDT Instances, The UEs 220a,220b can then use the retrieved FDT instance to decode the subsequently received FLUTE object packets and recover a respective file object.
Consequently, UEs 220a, 220b are able to receive a first FDT instance transmitted by BM-SC 200, in step 200, followed by and one or more files together with Forward Error Correction (FEC) data, in a subsequent step 220, A Forward Error Correction, FEC, building block defines e.g. the FEC code (RFC3452) and also an object partitioning scheme. The object partitioning scheme describes the split of the object data into UDP packet payloads. Each file will be encoded with one FEC encoding ID and generate the source encoding symbols and repair symbols. The applied FEC is included in the respective FDT instance.
The described procedures are typically repeated, here as illustrated with steps 230 and 240, until the MBMS session has been transmitted, here indicated by MBMS session stop 250. After the transmission has been completed the UEs 220a,220b will be able to report the result of the reception and, if required, to request file repair of content which has not been successfully received. Such a request is illustrated with step 260, where UE 220a requests for file repair, and where, in subsequent step 270, a file repair procedure is initiated, allowing any UE, here UE 220a, a second chance to receive missing file content, and in order to obtain a successful reception of the requested file content. The same procedure can be executed also for UE 220b in case this is found to be required.
Before the BM-SC 200 starts transmitting or broadcasting FLUTE packets to the UEs 220a,220b, the BM-SC 200 needs to send out user service description, including necessary information. During the delivery session, the BM-SC 200 also needs to send out FDT instances to describe the delivered file objects, as already mentioned above.
The UEs 220a,220b can use FDT instance information to know the file size, FEC encoding ID and FEC partition information. As FLUTE is based on UDP, generally the UEs 220a,220b cannot however know which packet is the last packet for one data file object unless the following conditions are satisfied:                1. the UE receives an A flag (session close flag) or B flag (object close flag), or        2. the FDT instance expire time is reached.        
In most cases, the broadcast session will broadcast the data files with some FEC overhead, or FEC redundancy level, to increase the possibility of successful recovery. But the FDT instance doesn't describe how much FEC overhead, or FEC redundancy level, that is added to the source file object. Two possible scenarios are described below.
Scenario 1: In a live streaming case, one delivery or broadcasting session has no associated delivery procedure for file repair. As a consequence of lack of FEC overhead, or FEC redundancy level, a UE will keep receiving packets even if the packet loss rate already exceeds the applied FEC overhead, or the FEC redundancy level percentage for one segment.
Scenario 2: In an on-request content delivery case, an Associated Delivery Procedure Description (ADPD) procedure is enabled for one delivery session, or broadcast session. In this case the UE identifies missing source symbols; and executes the following steps:                checks that PTP file repair is defined for the MBMS Download session (thus, file repair parameters are available),        waits until the file repair procedure can be started, wherein the UE calculates a (random) back-off time and selects (randomly) a file repair server (BM-SC), and        the client sends a file repair request to the selected file repair server.        
The starting time of the file repair procedure for the MBMS Download is the expiration time of the FDT instance at latest. The expiration time is given through the “expires” XML attribute of the FDT instance.
A back-off mode for MBMS download provides information as to when a receiver, i.e. a UE, that did not correctly receive some data from the MBMS sender, i.e. the BM-SC, during a broadcast transmission session, can request a repair session. A random time period may be defined in the mode that refers to the time window length over which a UE should calculate a random time for the initiation of the file repair procedure.
An operator cannot get a best guess about how many users may trigger file repair for one download, or broadcast, session until the file repair back-off mode has been reached when the broadcast delivery for this data file is finished and the UEs start sending file repair requests to one or more repair servers. In some extreme case there may be a huge amount of file repair requests during the file repair window for the same download session. Such a request flood will consume a lot of unicast bandwidth and the file repair server(s) may run a great risk of being overloaded. Preventing a potential file repair flood is especially valuable for a large file delivery, such as e.g. an Android update, as the small repair rate will still introduce a large repair amount in the network.